OpenEdge Deployment:<br />Managing 4GL Applications R-code execution environment

OpenEdge provides a dynamic environment for loading and executing r-code procedures from operating system files, standard procedure libraries, and memory-mapped procedure libraries. This execution environment consists of the following components:

Execution buffer — The portion of local memory that OpenEdge allocates and uses to store the chain of loaded r-code segments for all standard r-code procedures executing in local memory.

Session sort file (.srt) — A file that OpenEdge uses to dynamically swap standard r-code segments in and out of the execution buffer.

Shared memory buffer — The portion of shared memory that the operating system allocates and uses to store and execute the r-code segments for all memory-mapped r-code procedures.

Segment descriptor table — An in-memory table that references the r-code segments required by all executing procedures, including the location of each r-code segment in local or shared memory and usage count information.

R-code directory — An in-memory table that contains information about all r-code procedures executing in local or shared memory, including r-code size, usage count, segment descriptions, and a reference to the segment descriptor table for each segment.

OpenEdge loads and executes r-code procedures in different ways, depending on whether you store the r-code files in an r-code library and the type of library. The following sections provide an overview of how OpenEdge loads and executes r-code from an operating system file, a standard procedure library, and a memory-mapped procedure library.

Loading and executing r-code from a file

When loading an r-code procedure from an operating system file in a directory, OpenEdge opens the r-code file, loads the required r-code segments into local memory, and closes the file.

When executing an r-code procedure from an operating system file, OpenEdge accesses and executes the r-code segments in the execution buffer in local memory. OpenEdge also swaps segments to and from the session sort file, as necessary.

Loading and executing r-code from a standard library

When loading an r-code procedure from a standard library, OpenEdge opens the library file and loads the required r-code segments into local memory. The library remains open until the end of your Progress 4GL session or until you remove the library from the PROPATH. When OpenEdge needs to load an r-code segment for a procedure in that library, it accesses the open library in local memory. This is much faster than loading the same procedure from an operating system file.

When executing an r-code procedure from a standard r-code library, OpenEdge accesses and executes the r-code segments in the execution buffer in local memory. OpenEdge does not swap r-code segments to the session sort file unless you specify the PROLIB Swap (-pls) startup parameter. By default, OpenEdge reloads segments from the open library in local memory.

Loading and executing r-code from a memory-mapped library

When loading an r-code procedure from a memory-mapped library, OpenEdge opens the library and maps it in shared memory where multiple users can access it. The library remains mapped until the end of your Progress 4GL session or until you remove the library from the PROPATH. When OpenEdge needs to execute an r-code segment for a memory-mapped procedure, it accesses the library in shared memory. This is even faster than loading the same procedure from a standard library.

Tuning r-code execution

Table 5–1 lists the startup parameters you use to tune the r-code execution environment for a session.

Table 5–1: Startup parameters for tuning the execution environment
Startup parameter	Suggested use
Maximum Memory (`-mmax`)	Use this parameter to set the initial execution buffer ceiling. The default is 3096K. OpenEdge increases the execution buffer dynamically as required, but only after attempting to swap segments to the sort file. To minimize swapping I/O, increase this parameter.
Directory Size (`-D`)	Use this parameter to set the initial number of r-code directory entries. OpenEdge can reuse directory entries for inactive r-code files. However, reusing an entry requires some overhead. To reduce this overhead, increase the value of the `-D` parameter. The default is 100 entries, the minimum is 5 entries, and the maximum is 500 entries.
Stack size (-`s`)	When you load data definitions for very large tables or use recursive procedures, you might receive an error message directing you to increase this parameter. This parameter changes the size of the stack (an internal memory area used by Progress program modules).
Nested Blocks (`-nb`)	If memory is severely limited, use this parameter to limit the maximum number of nested procedure blocks allowed.

Tuning standard r-code libraries

Table 5–2 lists the startup parameters you use to tune standard r-code libraries for a session.

Table 5–2: Startup parameters for tuning r-code libraries
Startup parameter	Suggested use
PROLIB Memory (`-plm`)	If you have a large standard library or a memory shortage, use this parameter to allocate a 512-byte cache for the library’s directory instead of loading the entire directory into memory. This parameter slows the speed of library access but increases available memory.
PROLIB Swap (`-pls)`	Use this parameter to allow swapping from a standard library to a sort file. OpenEdge typically reads library-stored r-code from the library instead of swapping to a sort file. However, when storing the library over a network, swapping to a local sort file might be faster than accessing the remote library.

If you specify the PROLIB Memory (-plm) and PROLIB Swap (-pls) startup parameters with memory-mapped libraries, OpenEdge ignores them.